The advent of the World Wide Web (WWW) has made much more information available for use by anyone with a computer having an Internet connection. Unfortunately, current methods make it relatively easy to identify a particular user with specific data about the user, thus raising privacy concerns.
One problem with identification and privacy on the Web concerns how Web browsers obtain user data. Typically, Web browsers obtain user data from one or more cookies stored on a local hard disk. The cookies may contain sensitive user information. FIG. 1A is a flow diagram that illustrates a typical method for obtaining user information from a cookie. At 100, a Web browser accesses a Web site that uses a cookie. At 105, a determination is made regarding whether a cookie is present on the user computer's local disk. If a cookie is not present, at 110 the browser generates a cookie with the Web server Universal Resource Locator (URL) and Web server-provided user data. If a cookie is present, at 115 the browser uses the cookie on the user computer's local disk.
FIG. 1B is a block diagram that illustrates a cookie. A cookie 120 includes a server identifier and user data. The user data contains information about a user, such as the user's name and address.
Unfortunately, the privacy afforded by this approach is low because it is relatively easy to determine the identity of the user associated with the user data merely by examining the cookie contents.
Another problem with identification and privacy on the Web concerns user authentication. User authentication on the Web is typically accomplished using a username and password. FIG. 2 is a flow diagram that illustrates a typical method for performing user authentication using a username and a password. At 200, a user visits a service provider Web site. At 205, the service provider Web site authenticates the user based on a static username and password. This form of user authentication typically includes filling out a form for data that is deemed relevant for the services being rendered on the Web. At 210, a determination is made regarding whether the user authentication was successful. If the user authentication was unsuccessful, service is refused at 215. If the user authentication was successful, service is provided at 220. The privacy protection and security afforded by this approach are low.
Furthermore, the accuracy and appropriateness of the data gathered on the forms is not guaranteed. For example, if the service provider form completed by the user prompts for a drivers license number, the service provider typically does not determine whether the number entered by the user is appropriate for the service request (e.g. entering a fishing license number when prompted for a drivers license is inappropriate). And the service provider typically does not determine whether the entered drivers license actually belongs to the person who entered the number.
FIG. 3 illustrates how such user authentication problems are addressed using a “bricks and mortar” approach. FIG. 3 is a flow diagram that illustrates a typical method for paying for goods and services in person. At 300, a purchaser writes a check to pay for goods or services. At 305, a vendor requires credentials that will be appropriate for the method of user authentication needed to accept payment. Examples of such credentials include a driver's license and an ATM card. The user authentication provides a level of trust regarding the identity of the purchaser. Different levels of user authentication are afforded different types of transactions. For example, if the purchaser attempts to buy a relatively inexpensive item, the vendor might accept a check for payment without user authentication. If the purchaser attempts to buy a moderately priced item, the vendor might require one form of identification such as a driver's license. If the purchaser attempts to buy a relatively expensive item, the vendor might require additional forms of identification. Once the purchaser provides the required forms of user authentication (310), the vendor uses the required forms of user authentication to verify the truthfulness, accuracy and completeness of the credentials (315). If the vendor cannot satisfactorily verify the credentials, the transaction is rejected at 325. If the credentials are satisfactorily verified, the sale is completed at 330.
FIG. 4 is a block diagram that illustrates maintaining user-specific information on the World Wide Web. Each Internet user 400–425 accesses Web sites of service providers via a service provider Web server (435–460). Each Web server 435–460 authenticates the user by prompting for a username and a password. Each Web server 435–460 also maintains a separate set of user data for each (username, password) combination. The user data contains information about each user. For example, one Web site may store the zip code associated with the username so that the current weather at that zip code is presented whenever the user logs in to the Web site. Another Web site might maintain a list of items purchased at the Web site, so that information about similar products can be displayed when the user visits the site again.
Maintaining separate user authentication schemes for each Web site means that users must remember their username and password for each site. Oftentimes, an individual will use the same username and password for each Web site. Thus, once the users' username and password for one web site are known, the same username and password can be used to access information for the same user at another Web site. Moreover, individuals often base their username and password on personal information such as social security number or birthday. This makes passwords vulnerable to attack by hackers.
FIG. 5 is a block diagram that illustrates a centralized user authentication system. At 540 a user accesses a server access portal 505. At 545, the service access portal 505 collects user authentication data. If the user has already enrolled, the user is prompted for a username and password and ticket generator 520 interfaces with a user authentication database 524 to authenticate the user based on the username and password. Ticket generator 520 may be a Kerberos™ ticket generator. Ticket generator 520 interfaces with the user authentication database 525 to perform user authentication and to generate a user authentication token at 565. If the user has not yet enrolled, the user is prompted for user data and a chosen password at 545 and this information is sent to a user data generator 530. User data generator 530 interfaces with a user database 535 to store the user data. User data generator 530 also interfaces with the user authentication database 525 to provide user authentication information for the user. At 560, user data generator 530 interfaces with ticket generator 520 to generate a user authentication token. At 565 the user authentication token is returned to the service provider 505.
At 570, the user authentication token is returned to the user 500. The service provider 505 uses the user authentication token as a cookie or session identifier in subsequent communications (575, 580) between the user and the service provider. These communications may include requests 585 for user data stored in user database 535. Such requests 585 are received by user data retriever 515. Data retriever 515 retrieves the user data from user database 535 and returns the user data at 590.
Unfortunately, the service provider using this mechanism is a single point of control. A user has no control over where and when user data is obtained and where and when the service provider uses the user data. All user data is in the open once the user has identified himself.
FIG. 6 is a block diagram that illustrates a mechanism that provides a single logon for access to multiple Web sites. Global authenticator 305 authenticates a user 600–625 by prompting for a (username, password) combination. Once the user 600–625 is authenticated, the user can access each member Web site 635–660 without having to sign on to each particular Web site 635–660. Global authenticator 630 also maintains a profile for each username in global customer database 665.
As shown in FIG. 6, a user may visit multiple member Web sites once logged in via global authenticator 630. Thus, global customer database 665 must include information for a user that is relevant to all sites visited. For example, if a user visits a financial Web site and a medical plan Web site, global customer database 665 will include medical information as well as financial information. Moreover, global authenticator 630 may be configured to monitor or track an individual's Web activity such as the Web sites visited. Commingling potentially inappropriate data and the ability to monitor Web activity raise privacy concerns.
An additional problem with the using the World Wide Web is the lack of ways to create a trail of what a service provider accepts as valid user authentication. A user either logs in using a username and password that any person or program could have entered and is granted access to multiple services indefinitely, or the user enters the wrong username and password and gets nothing.
Accordingly, what is needed is a solution that protects privacy in a system where information about a user is required to deliver services. A further need exists for such a solution that enables service providers to exchange information about a person without revealing inappropriate or unnecessary information. A further need exists for such a solution that manages user transactions on an open network such as the Internet while maintaining privacy. A further need exists for such a solution that manages trust in user data and creates a trail of assessments of the trust and the process of how the assessments were made. A further need exists for such a solution that protects user data stored in cookies.